cc @jkotas, @janvorli

using System;
using System.Diagnostics;
using System.Runtime.InteropServices;

// Test various funceval scenarios that exercise DoNormalFuncEval
var dt = new DateTime(2026, 4, 12);
var list = new System.Collections.Generic.List<int> { 1, 2, 3 };
var str = "hello funceval";
int x = 42;
double pi = 3.14;
bool flag = true;
var dict = new System.Collections.Generic.Dictionary<string, int> { ["one"] = 1, ["two"] = 2 };
var arr = new int[] { 10, 20, 30 };
object boxed = 99;
var guid = Guid.NewGuid();
var span = "hello".AsSpan(); // not directly evaluable but interesting
var tuple = (Name: "Alice", Age: 30);

// Breakpoint here - then evaluate expressions in Watch/Immediate window:
//
// === Instance methods on value types (boxes 'this') ===
//   dt.ToString()              → value type instance method
//   dt.AddDays(1)              → value type method with arg, returns value type
//   guid.ToString()            → Guid.ToString()
//   pi.ToString("F1")          → double method with string arg
//   tuple.ToString()           → ValueTuple instance method
//
// === Instance methods on ref types ===
//   str.Length                  → string property (handle-based 'this')
//   str.Contains("func")       → string method with string arg
//   str.Substring(6, 4)        → string method with two int args
//   list.Count                 → generic ref type property
//   list.Contains(2)           → generic method with boxed int arg
//   list[0]                    → indexer (get_Item)
//   dict["one"]                → dictionary indexer
//   dict.ContainsKey("two")    → dictionary method
//   arr.Length                 → array property
//
// === Primitive 'this' (box + call) ===
//   x.ToString()               → int.ToString()
//   x.GetType()                → int.GetType() returns System.Int32
//   flag.ToString()            → bool.ToString()
//   x.CompareTo(10)            → int.CompareTo(int)
//
// === Static methods (this = null) ===
//   string.Concat("a", "b")   → static with ref type args
//   string.IsNullOrEmpty("")   → static with ref type arg
//   int.Parse("123")           → static returning primitive
//   Math.Max(3, 7)             → static with two primitive args
//   DateTime.UtcNow            → static property returning value type
//   Environment.ProcessId      → static property returning int
//   RuntimeInformation.FrameworkDescription → static property returning string
//   Guid.NewGuid()             → static method returning value type
//   Convert.ToInt32("42")      → static with string arg returning int
//
// === NEW_OBJECT (constructor) ===
//   new DateTime(2000, 1, 1)   → value type ctor with primitive args
//   new List<int>()            → ref type default ctor
//   new string('x', 5)        → string ctor with char + int
//   new object()               → simplest ctor
//
// === Boxed object ===
//   boxed.ToString()           → call on boxed int (ELEMENT_TYPE_OBJECT)
//   boxed.GetType()            → GetType on boxed int
//
Debugger.Break();

Console.WriteLine($"dt={dt}, list.Count={list.Count}, str={str}, x={x}");
Console.WriteLine($"dict={dict.Count}, arr={arr.Length}, guid={guid}, pi={pi}, flag={flag}");

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "funceval-test (branch)",
            "type": "coreclr",
            "request": "launch",
            "program": "c:\\temp\\runtime\\artifacts\\bin\\testhost\\net11.0-windows-Release-x64\\dotnet.exe",
            "args": ["exec", "C:\\temp\\funceval-test\\bin\\Debug\\net11.0\\funceval-test.dll"],
            "cwd": "${workspaceFolder}",
            "stopAtEntry": false,
            "env": {
                "DOTNET_ROOT": "c:\\temp\\runtime\\artifacts\\bin\\testhost\\net11.0-windows-Release-x64"
            }
        },
        {
            "name": "funceval-test (main)",
            "type": "coreclr",
            "request": "launch",
            "program": "c:\\temp\\runtime\\runtime2\\artifacts\\bin\\testhost\\net11.0-windows-Release-x64\\dotnet.exe",
            "args": ["exec", "C:\\temp\\funceval-test\\bin\\Debug\\net11.0\\funceval-test.dll"],
            "cwd": "${workspaceFolder}",
            "stopAtEntry": false,
            "env": {
                "DOTNET_ROOT": "c:\\temp\\runtime\\runtime2\\artifacts\\bin\\testhost\\net11.0-windows-Release-x64"
            }
        }
    ]
}

Results match main branch:

PR	Main

Tagging subscribers to this area: @steveisok, @tommcdon, @dotnet/dotnet-diag
See info in area-owners.md if you want to be subscribed.

Built on top of #126542.

Does it depend on any of the changes in #126542 given that it just calls the public MethodInfo.Invoke API?

Built on top of #126542.

Does it depend on any of the changes in #126542 given that it just calls the public MethodInfo.Invoke API?

#126542 moved InvokeMethod to managed and this is tested end to end that way. I can cherry-pick ffa8a51 on main if we want this one to go in first.

I am not sure which one will go first. If these changes are independent, it would make more sense to submit them as independent PRs.

Failures are known, the new one is unrelated deadlettered leg. Results still match before/after #126809 (comment)

Let me run the private diagnostic tests with this change.

There is about 15 failed tests with this change (compared to the commit right before your change). Moreover, I've found that we also have some additional failures in these tests that one of your previous changes - #126222 has introduced. Since I have run those tests at one point during your PR, it seems that some changes made after that has introduced the problem.
Let me get my head around these failures and then get back to you.

So, regarding the issues introduced by the old PR, the DacDbiInterfaceImpl::UnwindStackWalkFrame needs to be updated to skip frames of "System.Environment.CallEntryPoint". I've tried a quick hack (just comparing method name string) and found that fixes two of the three EH related failures.
We probably also want to skip it in the ProfilerStackWalkCallback, DebuggerStepper::IsInterestingFrame and maybe handle it in the DacDbiInterfaceImpl::GetStackWalkCurrentFrameInfo too (create a new enum entry in FrameType, return it from there and handle it in CordbStackWalk::GetFrameWorker). See my old PR that ported the NativeAOT EH, you'll see where I've added this handling.

The remaining issue from the old PR is strange. The debugger can see a stack where the System.Environment.CallEntryPoint is at the top of the stack, with Main at the bottom. That doesn't make sense, I am looking at the test to see if I can isolate a standalone repro.

@janvorli, thanks. I think the old approach (with MethodDescCallSite machinery) was treating IsElementTypeSpecial differently and only creating strong handle for AllBoxed. I have split that in ee224c6.

Can we create separate PR with fixes to these regressions? I would like to get to a clean state first before taking more risky changes.

I was thinking to push the commits here for now then split PR once private diagnostics test pass. Cherry-picking these is simple as they are touching different files. It's to reduce the hassle for @janvorli to switch between branches.

Moved those changes to #126927 and reverted here.

@am11 even after your last change it doesn't work. I can see that the DoNormalFunceval took the expected path, the pDE->m_resultType was System.String, the ucoGc.resultObj was of type System.String.

So I've spent more time debugging it and it turns out the problem is actually at the funceval arguments processing. The thing is that the debugger calls ToString on the struct via funceval. But we end up boxing the "this" argument. The original code didn't do that - dumping the type of *pObjectRefArray after the call to BoxFuncEvalThisParameter is the struct in the old state case, but the type ucoGc.thisArg in your case is System.Object.

It seems the original code would only box "this" argument if argData[0].argElementType == ELEMENT_TYPE_VALUETYPE and when not pDE->m_md->GetMethodTable()->IsValueType()

@janvorli, based on your description, I have pushed a change. When pFEArgInfo is NULL (the 'this' arg), it reads the concrete type from fullArgType instead of using the declaring type of the method.

@am11 the issue with structs, delegates and generic structs is now gone. However, it breaks the funceval test of a method returning bool - it now returns wrong value (true instead of false). And there is another similar case when a funceval of float returning method returns completely wrong float. I think you probably cannot handle regular args and this the same way - the original code had a separate methods handling of args and this.

@janvorli, that value type regression was caused by previous commit. It was checking if objectref is value type rather than its corelement type.

@am11 now all the failures I've seen are gone.

@dotnet/dotnet-diag-contrib Any concerns with this change?

It is switching funceval to use reflection invoke. It makes the code a lot simpler and fully portable that is going to help with the wasm port.

Thanks, will keep an eye out post-merge for any fallouts after daily SDK is released. (I think folks will be able to test conveniently after the signed binaries are out)

@jkotas, @am11 - @tommcdon has ran our Visual Studio tests suite that is more extensive than the diagnostic tests I've ran and found that this change breaks multiple tests there. He's going to look into those failures, so please let's hold on until he figures out what's wrong.

Tested after merging main, seems to be working for most vals

If I know what type of cases have the problem, I can try to debug and fix them.

@janvorli, @tommcdon, a note: this branch should be built from clean state (i.e. after deleting artifacts dir). I noticed that cmake or ninja doesn't reinstall some DAC related stuff if we built main before rebuilding this branch and we run into mismatch error when using debugger in VS with $env:VSDebugger_ValidateDotnetDebugLibSignatures=0. In all previous screenshots, I built clr from clean state.